GTM Server Side Tracking

@2022 勉強しなおし

App Engineが用意されていて、それを使う。standardでもflexibleでも行けるが、本番は flexibleが推奨されてる。

理由は、よくわからないけど、最終的に、flexibleで自分の責任でやってね？という意味？

code: standardの package.json

{

"name": "gtm-cloud-image",

"version": "1.1.0",

"main": "server_bin.js",

"scripts": {

"start": "node server_bin.js"

},

"dependencies": {

"cacheable-lookup": "6.0.4",

"flags": "0.1.3",

"@google-cloud/bigquery": "~5.11.0",

"google-auth-library": "~7.14.0"

}

}

ブラウザから tracking serverにrequestを送るために、普通のGTMには、transport urlフィールドがあるし、GA用の設定もある

製品開発は進んでる

community template

server side tag専門のagency?

導入メリット

カスタムドメインにしてリクエスト先を、サブドメインでは違うが同一ドメインにできる

クライアント側の負担を、server側に一部移すことは可能

server側なので、ブラウザ側の事を気にせずに処理が書ける

BigQueryへのinsertや、

あとは、いろいろできそう

デメリット

学習コスト(初期・運用)は大きい。

app engineの費用もどれくらいかは分からないが、1 instanceごとに4000円/月(f1 machine?)くらいのイメージ?

とりあえず、 テスト環境といわれるstandardで運用してみてる。

// 以下は、2020のメモ

Tealiumが先行事例

@202008 時点での解説

これまでのbeaconをそのまま送る話

なぜかというと、Server-side GTMはWebサイトからのGAビーコンを受け取ってGAサーバーに転送するためのリバースプロキシなので、細かい設定は「Webサイト用GTM」側で行います

app engineのlogは stack driverに残るので、実は beaconの検証はやりやすくなるかもしれない、と思った。

最初に聞いた際の思った事 @202001

server(container管理含む)を誰がするか、

domainは、サイトのdomain. (ここは、大した問題ではない？）。少なくとも、ドメイン単位での管理を想定すれば、、そうでないケースもあるが、

server側でいろいろできるのがメリットだが、スクラッチでやりたい人はいない。

ウェブサーバー機能(browserからのリクエスト受け付け)

(http?, もっと簡略化したprotocol?)クライアント機能

管理画面から、設定を受け付ける機能

このあたりを提供してくれる、プロダクトで、付随するサービスも生まれる可能性はある。

思想的？に、ブラウザ側でのトラッキング機能をシンプルにして、管理しやすくしようというのはある。

トラッキングで、ユーザー側の管理をしやすくできる方向にも沿う流れ?